Thorsten,

(if you would like to answer, please: provide code snippets
or something; not just general thoughts)

I asked you about aportable way of storing/loading of a
*single* number. You failed? You started to talk about non-IEEE
fp numbers... Thorsten, I state that non-IEEE numbers
represent a lesser problem then multicharacter constants.
If your platform/compiler deal with such numbers, for some
reason, you still can output them as, say

  fprintf( my_file, "%g", my_non_IEEE_number );

and then *reliably* read in (on a different platform) as

  fscanf( my_other_file, "%g", &my_IEEE_number );

With your multicharacter constants, what are you going to do?

Your assumption about integers' representation not been
standartized is, again, wrong. According to ISO, there is a single
possible representation for unsigned integers, plus several
possible representations for signed numbers. If I were
concerned about portability of signed integets (which is normally
not the case), I would store them as n-INT_MIN, and, after
reading, would convert to n+INT_MIN. That would be rock-solid.

Now about MKFOURCC -- you just don't understand. You write:

> What the macro is actually doing most of the time (not always!) is add
> enough garbage to get certain compilers to not complain about the
> multicharacter constants.  Apart from this, it can only change the bit
> order, which in turn, assuming some common sense and will only be an issue
> of byte order.  This in turn will be covered by the regular byte order
> conversion you need to do anyway when reading/writing from/to disk

The keywords here are 'byte order conversion'. Even just the term
'order'. This statement implies knowledge of that 'order'. And you
always have that, on each platform -- for short, int, long, float, double,
whatever -- but not for multicharacter constants. Endianness is
one thing, storing characters within long is another thing. You *first*
pack characters into 'long' (this is governed by some INTERNAL
compiler rules, UNAVAILABLE to mere mortals), and *then* put
that 'long' into memory (this is governed by 'endianness').

That's just plainly non-portable. To be able to convert, you have to
know *WHAT* on Eath do you have.

Phew...

Post a reply to this message